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DECISION ON APPEAL 1 



1 The two-month time period for filing an appeal or commencing a civil 
action, as recited in 37 C.F.R. § 1.304, or for filing a request for rehearing, 
as recited in 37 C.F.R. § 41.52, begins to run from the "MAIL DATE" 
(paper delivery mode) or the "NOTIFICATION DATE" (electronic delivery 
mode) shown on the PTOL-90A cover letter attached to this decision. 



Appeal 2009-006351 
Application 10/624,353 

STATEMENT OF THE CASE 
This is an appeal under 35 U.S.C. § 134(a) from the Examiner's 
rejection of claims 1-7 and 11-18, which are all of the pending claims. 2 
We have jurisdiction under 35 U.S.C. § 6(b). We reverse. 



A. Appellants ' invention 

Appellants' invention relates to a method, a computer program 

product, and a device for streaming a media file over a distributed 

information system, such as the Internet, to a client computer running a 

browser application. Specification 1:4-7. 3 The invention is summarized in 

the Specif cation as follows: 

First, a server receives a request for a particular media file from 
the client computer. Then, the server provides a metafile[,] e.g., 
by dynamically generating the metafile or, alternatively, statically 
querying the metafile from a respective data storage, whereby said 
metafile contains information about the identification, location 
and format of the media file, and returns it back to the client 
computer. Advantageously, the server intercepts a download 
request for the actual media file and reinterprets the download 
request in[to] a request for receiving a corresponding metafile. 
Thus, instead of returning the requested media file, a metafile is 
returned that allows immediate streaming of the requested media 



2 The Examiner, as noted at page 2 of the October 15, 2007, Advisory 
Action, approved entry of a September 24, 2007, Amendment canceling 
claims 8-10. 

3 Citations herein to Appellants' Specification ("Spec") are to the 
Application as filed rather than to corresponding Patent Application 
Publication 2004/0078470 Al. 
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file without the need of waiting for the download to be finished. 
Id. at 6:4-12. 

Figure 1 of the Application is reproduced below. 
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Figure 1 is a block diagram illustrating a system 100 in accordance 
Appellants' invention (id. at 9:4-5). In web client 102, the web browser 122 
composes an HTTP (Hypertext Transfer Protocol 4 ) request for a particular 
media content file and sends the request to network interface 124 (id. at 



4 Spec. 2:17. 
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11:14-15). Regarding generation of this HTTP request, the Specification 
explains that 

[a] user clicking an HTML [Hypertext Markup Language 5 ] 
document link may initiate this action. Alternatively a user may 
initiate this action by typing the request URL [Uniform Resource 
Locator 6 ] into the browser[']s URL input field. Please note that 
the request URL points to the media file itself, and neither to a 
streaming metafile nor a CGI/Java Servlet program component. 

Id. at 1 1:15-19. The HTTP request is received by network interface 134 in 

metadata server 104 and forwarded to an HTTP protocol handler 132 in that 

server (id. at 11:14-25). In contrast to a conventional HTTP protocol 

handler, which answers an HTTP request either by returning the content of 

the resource requested (default HTTP behavior) or by executing the resource 

and forwarding its reply (Java Servlets, CGI scripts), HTTP protocol handler 

132 "reinterprets the HTTP request so that it returns streaming metadata" 

(id. at 12:1-5), i.e., metadata about the requested data stream or steams. 

Specifically, HTTP protocol handler 132 obtains the metadata for the 

requested media resource from the metadata generator 136 or from the 

metadata query component 138 (id. at 12:5-7). In either case, the resulting 

"streaming metadata" is returned to HTTP protocol handler 132 (id. at 

12:18-19). This streaming metadata is accompanied by a MIME 

(Multipurpose Internet Mail Extension)-Type suitable for the streaming 

metadata (id. at 12:19-21). 

5 Spec. 2:13-14. 

6 Spec. 4:20-21. 
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HTTP protocol handler 132 sends the streaming metadata and MIME- 
Type through network interfaces 134 and 124 to web browser 122, which 
analyzes the MIME- Type, selects a suitable multimedia player 126 based on 
this information, and forwards the streaming metadata information to the 
multimedia player (id. at 13:8-11). The multimedia player analyses the 
streaming metadata passed to it and extracts all relevant information, such as 
which streaming server to contact, which streaming protocol to use, and 
which file to stream (id. at 13:12-14). Streaming protocols may be RTSP 
(Real Time Streaming Protocol 7 ), HTTP, or proprietary protocols, depending 
on the streaming technology provider (id. at 13:14-15). Next, multimedia 
player 126 composes a streaming protocol request and sends it via network 
interface 124 to network interface 146 on delivery server 106 (id. at 13:15- 
19). Delivery server 106 transfers real-time protocol packets via network 
interfaces 146 and 124 to multimedia player 126, which renders their content 
as they arrive (id. at 14:1-14). 

B. The claims 

The independent claims before us are claims 1, 11, and 18, of which 

claim 1 reads as follows: 

1 . A method for streaming a media file over a distributed 
information system to a client computer running a browser 
application, the method comprising the steps of: 



7 Spec. 3:10-11. 
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receiving a request for a particular media file from a client 
computer, 

providing a metafile, wherein said metafile contains 
information about the identification, location and format of the 
media file, 

returning said metafile back to said client computer, 

characterized in that 

the step of receiving a request for a particular media file 
from a client computer comprises the steps of: 

intercepting a download request for the actual media file 

and 

reinterpreting said download request into a request for 
receiving a corresponding metafile. 

Claims App. (Br. 24). 8 

Appellants, in identifying the support for claim 1 in the Specfication, 

read the step of "receiving a request for a particular media file from a client 

computer" on the receipt by metadata server 104 of the HTTP request 

generated by web client 102 (Br. 8) and read the recited "metafile" that is 

returned back to the client computer on the "streaming metadata" transmitted 

by metadata server 104 to web client 102 (id. at 9). 

C. The reference 

The Examiner's rejections are based on the following reference: 

Klemets US 2003/0236912 Al Dec. 25, 2003 

In the discussion of the anticipation rejection, the Examiner also relies 

on H. Schulzrinne et al., Network Working Group, Request for Comments: 
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2326, Category: Standards Track (April 1998) [hereinafter "Schulzrinne"]. 
Final Action 7-8. 

D. The rejections 

Claims 1-4, 6-14, and 16-18 stand rejected under 35 U.S.C. § 102(e) 
for anticipation by Klemets. Final Action 2, para. 3. 9 

Claims 5 and 15 stand rejected under 35 U.S.C. § 103(a) for 
obviousness over Klemets. Id. at 5, para. 5. 



THE ISSUE 

The dispositive issue raised by Appellants' arguments is whether the 
Examiner erred in reading the recited "download request for the actual 
media file" (claim 1) on Klemets' s DESCRIBE request. 10 



ANALYSIS 



8 Apeal Brief filed December 19, 2007. 

9 Although claim 18 is not identified in the statement of the rejection at 
page 3, paragraph 3 of the Final Action, that claim is addressed at page 5 
thereof in the discussion of the rejection. 

10 See Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential) 
("If an appellant fails to present arguments on a particular issue — or, more 
broadly, on a particular rejection — the Board will not, as a general matter, 
unilaterally review those uncontested aspects of the rejection."). Designated 
as precedential at 

http://www.uspto.gov/ip/boards/bpai/decisions/prec/index.jsp. 
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Klemets's invention relates to content streaming and more particularly 
to embedding a streaming media format header within a session description 
message. Klemets [0002], [0003]. 

Figures 1 and 3 are reproduced below. 
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Figure 1 is a block diagram of Klemets's system (id. at [0030]), and 
Figure 3 is an exemplary flow diagram illustrating the interaction between 
the client and the server for initiating a streaming media session (id. at 
[0023]). 

8 
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To initiate a session, the client 106 sends a description request (e.g., 
an RTSP DESCRIBE request) to the server 104 to obtain a description of the 
available content (id. at [0041]). Server 104 responds by encapsulating the 
streaming media format header within a description message (e.g., an SDP -- 
Session Description Protocol 11 — message) and transmitting the description 
message via a description protocol (e.g., SDP) to the client 106 (id.). The 
SDP message includes a streaming media format file header and a content 
description list (id. at [0031]). The client 106 then initiates a connection to 
the server 104 using a RTSP SETUP command (id. at [0045]). The client 
106 is free to choose which streams it wants to SETUP (i.e., receive from the 
server 104) (id.). The client 106 can, for example, issue a separate RTSP 
PLAY request for each stream that has been chosen (id.). 

The Examiner reads the claim 1 step of "receiving a request for a 
particular media file" on the receipt, by media server 104, of a DESCRIBE 
request. See Final Action 8 ("the RTSP DESCRIBE method requires 
identification of a particular media file . . . , which is typically identified by a 
specific URL."). As support for the finding that an RTSP DESCRIBE 
request identifies a particular media file, the Examiner relies on the 
discussion of an RTSP DESCRIBE request in Section 10.2 (at pages 31-32) 
of Schulzrinne. Id. at 7-8. In the October 15, 2007, Advisory Action, the 
Examiner further finds (at page 3) that "the RTSP DESCRIBE message is a 
request for [initiating] a particular media file") (brackets in original). 



11 Klemets [0007]. 
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Appellants responded to the Examiner's reading of the "request for a 
particular media file" on Klements's RTSP DESCRIBE request by arguing 
that 

[t]he RTSP DESCRIBE request disclosed in the Klemets et 
al. reference is clearly not a request for a particular media file as 
required by each of independent claims 1 and 1 1 . The RTSP 
DESCRIBE request disclosed in the Klemets et al. reference is 
merely a request from the client to the server to describe the 
available content. See, Klemets et al., page 2, paragraph [0015] 
and paragraph [0016]; and page 4, paragraph [0041]. 

(Br. 16-17.) Because Appellants have not challenged the Examiner's above- 
quoted finding that an RTSP DESCRIBE request identifies a particular 
media file, we understand Appellants to be arguing that the DESCRIBE 
request nevertheless is not "a request for a particular media file" (emphasis 
added), as required by the claim. We agree with the Examiner that this 
claim language is broad enough to read on a request with regard or respect 
to a particular media file and thus is broad enough to read on the DESCRIBE 
request (Answer 8). 

Appellants next argue that "the RTSP DESCRIBE request does not 
involve the steps of intercepting a download request for the actual media 
file , and reinterpreting the download request into a request for receiving a 
corresponding metafile as further required by each of independent claims 1 
and 11" (Br. 17). The Examiner responded to this argument by discussing 
the meaning of the recited "download request for the actual media file" 
separately from the meanings of the terms "intercepting" and 
"reinterpreting." Regarding the recited "download request for the actual 
10 
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media file," the Examiner concludes that this claim language does not 

necessarily mean a request to download the actual media file: 

[T]he phrase "intercepting a download request for the actual 
media file" does not necessarily mean that the request is a request 
to download the actual media file. . . . [T]he phrases "for a 
particular media file" and "for the actual media file" could mean 
either that the request is to acquire, or download, the media file 
(which is the interpretation that Appellant is apparently relying 
upon), or that the request is with regard or respect to a particular 
media file (which is clearly within the scope of the instant claims, 
and is the interpretation relied upon by the Examiner). 

(Answer 8.) We agree with Appellants that the Examiner's interpretation of 

the phrase "download request for the actual media file" is unduly broad. 

When that phrase is viewed in light of the further recitation of 

"reinterpreting said download request into a request for receiving a 

corresponding metafile," it is clear that the "download request for the actual 

media file" is a request to download the actual media file rather than a 

request to download information with regard to or with respect to the actual 

media file. Because the Examiner apparently agrees with Appellants that the 

"download request for the actual media file" so interpreted does not read on 

Klemets's DESCRIBE request, we will not sustain the anticipation rejection 

of: (a) claim 1; (b) independent claims 11 and 18, which include limitations 

similar to those recited in claims 1; and (c) dependent claims 2-4, 6, 7, 12- 

14, 16, and 17, which are not separately argued. In re Nielson, 816 F.2d 

1567, 1572 (Fed. Cir. 1987). 
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For the same reason, and because the Examiner does not alternatively 
rely on obviousness to remedy the above-noted deficiency, we will not 
sustain the rejection of claims dependent 5 and 15 under 35 U.S.C. § 103(a) 
for obviousness over Klemets. 

DECISION 

The Examiner's decision that claims 1-7 and 11-18 are unpatentable 
over the prior art is reversed. 



REVERSED 



gvw 
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